La conversación sobre RAG en 2025 es distinta de la de 2023. Hace dos anios el tema era elegir la mejor base vectorial y decidir cuantos tokens caben en el contexto. Hoy el termino RAG esconde sistemas hibridos que combinan varias fuentes de recuperacion, grafos que capturan relaciones entre entidades y capas de reordenamiento que acercan la respuesta a lo que el usuario necesita. Este post recoge lo que he aprendido montando RAG 2.0 en varios proyectos durante los últimos meses, que piezas aportan valor real y cuales son moda sin sustancia.
Por que el RAG original ya no basta
El RAG de primera generación se basaba en una idea simple: dividir los documentos en fragmentos, calcular embeddings, guardarlos en una base vectorial, buscar los fragmentos mas similares a la pregunta y pasarlos al modelo para que generara la respuesta. Esta idea funciona bien cuando la pregunta se corresponde directamente con el texto: “cual es la politica de devoluciones”, “que dice el manual sobre calibracion del sensor”.
Falla cuando la pregunta requiere combinar información de varios fragmentos que no son individualmente similares. “Que empleados colaboraron con el proveedor X en proyectos europeos” es una pregunta donde la respuesta no esta en ningun fragmento concreto; esta en la relacion entre varios. La base vectorial devuelve fragmentos relevantes por similitud lexica pero no por relacion estructural, y el modelo tiene que inferir lo que no puede saber.
El otro fallo clasico es el de palabras clave específicas. Si alguien pregunta por un código de error concreto o un número de referencia, la busqueda vectorial puede fallar porque los embeddings no capturan bien identificadores raros. La busqueda lexica pura, la de toda la vida, funciona mejor en esos casos. El RAG de 2023 ignoraba esta realidad porque la novedad era lo vectorial.
Lo que anade la busqueda hibrida
La primera mejora de RAG 2.0 es la busqueda hibrida: combinar busqueda vectorial con busqueda lexica (BM25 clasico) y fusionar resultados con una función de ranking. En mis pruebas, esta combinacion simple sube la calidad de los fragmentos recuperados entre un 15 y un 30 por ciento respecto a vectorial pura, dependiendo del dominio.
El ajuste importante es la proporcion. Dar el mismo peso a ambas fuentes suele funcionar peor que dar mas peso a una segun el tipo de pregunta. Para consultas con terminos técnicos raros, mas peso lexico. Para consultas conceptuales, mas peso vectorial. Algunos sistemas usan un clasificador ligero para decidir la proporcion por consulta; otros mantienen una media ajustada al dominio.
La fusion mas robusta que he visto no suma ponderadamente los scores sino que combina rangos: usa el mejor rango del documento en cualquiera de las dos busquedas, con una penalizacion por aparecer solo en una. Este enfoque evita el problema de las escalas de score distintas entre metodos y tiende a devolver resultados menos sensibles a la calibracion.
Grafos de conocimiento como capa estructural
La segunda pieza de RAG 2.0 es el grafo de conocimiento. En lugar de tratar los documentos como texto plano, el sistema extrae entidades (personas, proyectos, conceptos) y relaciones entre ellas. El resultado es un grafo donde nodos son entidades y aristas son relaciones explicitas.
Cuando llega una pregunta que pide combinar información, el sistema puede navegar el grafo para encontrar entidades conectadas y usar esa información estructural junto con los fragmentos textuales. “Que empleados colaboraron con el proveedor X en proyectos europeos” se convierte en una consulta de grafo que devuelve las entidades relevantes con sus relaciones, y el modelo genera la respuesta con ese contexto ya ordenado.
El grafo no reemplaza los embeddings, los complementa. Los embeddings siguen siendo la forma de encontrar texto semanticamente parecido; el grafo aporta la información de relaciones que los embeddings no capturan bien. La combinacion es lo potente.
Construir el grafo sin matar el proyecto
El problema práctico de los grafos es que construirlos a partir de texto no estructurado es caro. La extracción automática con modelos de lenguaje funciona pero deja errores: entidades duplicadas con nombres ligeramente distintos, relaciones espureas, omisiones. Si el grafo tiene demasiado ruido, la ganancia de usarlo se pierde rapidamente.
Lo que he visto funcionar es un enfoque escalonado. En la primera pasada, extracción automática con un modelo eficaz y un esquema acotado de tipos de entidad y de relacion. En la segunda, normalizacion de entidades por similaridad y por reglas simples de canonicalizacion. En la tercera, revision humana de las relaciones de alta cardinalidad antes de aprobar el grafo para uso. Saltar la tercera fase es tentador pero paga caro en forma de respuestas incorrectas con apariencia de seguridad.
La alternativa cuando el dominio ya tiene una taxonomia formal (productos catalogados, empleados en un directorio, proyectos en un sistema de gestión) es usar esa taxonomia como columna vertebral del grafo y enriquecerla con relaciones extraidas del texto. Partir de estructura existente siempre es mas barato que construirla desde cero.
Reranking, la capa que no se ve
La tercera pieza de RAG 2.0 es el reranking: un modelo que toma los fragmentos recuperados por la busqueda hibrida y los reordena segun su relevancia para la consulta concreta. El reranker no indexa nada; opera solo sobre los candidatos que ya han salido de la fase de recuperacion.
Los modelos de reranking actuales son cross-encoders especializados. Miran la pregunta y cada candidato conjuntamente, lo que les da mejor sensibilidad que los encoders que procesan cada uno por separado. El coste es mayor por candidato, pero como solo se ejecutan sobre los top 50 o 100, el impacto es asumible.
En mis pruebas, anadir un reranker sube la precisión de los top 5 fragmentos entre un 10 y un 20 por ciento adicional sobre la busqueda hibrida. Es una mejora consistente y el coste por consulta es moderado. En RAG 2.0 es una pieza casi obligada si el caso de uso es serio.
Las trampas de la evaluación
Disenar un RAG 2.0 sin evaluación rigurosa es apagar el panel de vuelo y navegar por intuicion. Las trampas son varias y valen una mencion. La primera: usar el propio modelo generador como juez de la calidad de sus respuestas produce optimismo sistematico. Los jueces deben ser independientes, idealmente humanos para un conjunto de referencia y un modelo distinto para evaluación automatizada continua.
La segunda trampa es medir solo en consultas tipo. Los sistemas que dan respuesta perfecta a las 20 consultas del equipo de producto pueden dar respuesta mediocre a las 2000 consultas que realmente hacen los usuarios. Recoger preguntas reales, anonimizar y evaluar contra ese conjunto es mas revelador que disenar un banco de pruebas en despacho.
La tercera es ignorar los casos en los que el sistema deberia decir que no sabe. Un RAG que inventa con seguridad cuando la información no esta en el corpus es peor que uno que responde poco pero bien. En la evaluación, incluir casos de preguntas sin respuesta y medir la tasa de alucinacion es tan importante como medir la tasa de acierto.
Lo que no ha cambiado
Hay cosas que no han cambiado entre 2023 y 2025 y conviene recordarlas. La calidad del corpus sigue siendo la variable que mas pesa: datos limpios, con metadatos correctos, con actualizaciones frecuentes. Un RAG de arquitectura sofisticada sobre datos sucios rinde peor que un RAG simple sobre datos curados. El cuello de botella casi nunca es la arquitectura.
El chunking, la division del texto en fragmentos, sigue siendo mas arte que ciencia. Fragmentos de tamanio fijo funcionan decentemente pero no son optimos en documentos con estructura interna fuerte. Fragmentos con solapamiento mejoran la cobertura pero encarecen el índice. Fragmentos por secciones semanticas pueden ser mejores pero requieren conocer el dominio. No hay receta universal.
El coste de mantenimiento tampoco ha bajado. Reindexar corpus grandes cuando los documentos cambian sigue siendo caro. Mantener un grafo al dia cuando las relaciones evolucionan exige procesos de actualizacion periodica. RAG 2.0 no es plug and play; es un sistema vivo que hay que cuidar.
Como pensar la decision
Mi recomendacion para quien empieza un proyecto RAG en 2025 es escalar la arquitectura al problema. Si la pregunta del caso de uso se corresponde con texto directamente, vectorial puro con buen corpus puede bastar. Si hay mezcla de preguntas conceptuales y de identificador, anadir busqueda lexica es fácil y rentable. Si las preguntas requieren combinar información estructural, merece la pena plantear grafo.
Saltar a RAG 2.0 completo desde cero es tentador pero rara vez rentable. La complejidad crece rapido, los bugs se multiplican y la capacidad de diagnosticar por que una respuesta es mala se reduce. Mejor empezar simple, medir que tipo de preguntas falla, y anadir la capa correspondiente cuando el fallo lo justifique.
Creo que en un anio la arquitectura de RAG sera menos discusion sobre piezas y mas sobre sistemas integrados donde la recuperacion, el reranking y los grafos conviven sin ser conscientes unos de otros. Las plataformas que lo ofrezcan llave en mano ganaran a las que exijan ensamblar piezas sueltas. Pero mientras llega esa madurez, entender las piezas individuales sigue siendo la forma de montar algo que funcione en 2025 sin quedarse colgado de las promesas.
